1. Field of the Invention
The present invention relates to command line input to server systems management utilities and more particularly to dynamically updating and scaling a command line parser using a centralized data schema.
2. Description of the Related Art
As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
Information handling systems can include subsystems that monitor the physical health characteristics of system components, such as temperature, voltage, fans, power suppliers and chassis intrusion. Subsystems can also store system level administration information such as warranty information for a system or a date of purchase or manufacture. Subsystems can also store enclosure level administration information such as a number of available memory slots and a number of used memory slots. Such subsystems can also monitor hardware detected faults in the operation of the system components. Conventional monitoring subsystems can be configured by specific commands that set variables associated with the operation of those subcomponents. These commands may be generated via a command line utility.
It is desirable for a command line utility to contain code to parse the command line input, validate the input, and perform some task based on the content of the input. The input generally includes an option, usually denoted by a delimiter such as ‘/’ in a DOS environment or ‘—’ in a Linux environment, and an argument to the option. Together this option/argument pair provides a command line interface (CLI) command. In some cases the argument to the option may be optional, making the option the only component of a command. Many commands may be included within a particular command line.
There are many known parsing solutions. However, known parsing solutions present a number of challenges. For example, data relating to CLI options may be distributed in the code of the utility, making it harder to completely define within a command the behavior of a CLI command. For example, one module may contain the string name of the option, while one module may contain the argument string for the option, while yet another module might contain the data to manipulate if this option is given on the command line. Thus, adding new CLI options can be tedious, repetitive and distributed. If a developer wants to change the name of a CLI option, the argument to the option from mandatory to optional, and the action when the option is given as input, then the developer would need to make changes to three different sections of code within the utility.
Another challenge of known parsing solutions relates to limitations in providing scalability with multiple CLI option levels. Some CLI applications have many levels of commands called subcommands. For example, a baseboard management controller (BMC) configuration utility has commands grouped for configuring a local area network (LAN) channel, a serial channel and Event Filters. The LAN option in turn has sub-options, such as ipaddress, gateway, and subnetmask, which may be represented in command line as:
bmccfg lancfgparams—ipaddress
bmccfg lancfgparams—gateway
bmccfg lancfgparams—subnetmask
Known parsing solutions parse the first level of commands, pass the information to the implementation modules, and then begin a second parsing operation for the subcommands. With this approach, the amount of distributed CLI data may be multiplied by the number of sub commands.
Another challenge of known parsing solutions is that compile time coupling of CLI options with corresponding data restricts maintenance of the application. Known parsing solutions perform a compile time coupling of command line options to corresponding implementation data. If data changes or needs to be removed from the utility (due to, for example, broken function), then the utility would generally require recompilation and redistribution. Recompilation often lengthens the test-debug-fix cycle and complicates patch management during maintenance of the utility. Any change to the CLI would require a new release of the code.
One solution to the parsing and scaling of command line instructions is disclosed in O'Hara, U.S. Patent Application Publication No. 2004/0103178 A1, entitled “Information Handling System and Method for Multilevel Command Implementation” (O'Hara). O'Hara discloses a process for transforming name/value pairs from the command line to name/value pairs for back-end libraries and routing these new pairs to the appropriate library. O'Hara discloses a second level of command line parsing within the back-end libraries as well as statically linking the code that validates and applies the command to the name/value pairs.